Traditionally, networking features and protocols in network devices have been implemented by hardware-dedicated ASIC designs. These fixed ASIC designs limit the rate of deployment of new protocols. In addition, the hardware changes to support new protocols are expensive in term of both cost and time. As a result, designs of programmable networking devices, which allow users to deploy new features and protocols by means of software have been becoming more attractive.
One approach to programmable networking devices is to implement the protocols in software running on state-of-the-art general-purpose CPUs. The processing capacity at maximum of 64 bits of state-of-the-art general-purpose CPUs, however, cannot guarantee real-time performance for current networking systems, which support network packet flows up to hundreds of Gbps.
Alternatively, reconfigurable FPGA chips have been also used to implement network features in programmable network devices. Their limitations in logic cell capacity of the FPGA chips, however, do not allow them to process network packets with large sizes of hundreds of bytes at line-rate throughput. In addition, the high complexity in their internal interconnect wirings makes the FPGA chips running at low frequency with high latency, which are not appropriate for complex network features required in new enterprise and data-center networks.
In practical networks, each packet often encapsulates many header fields representing different protocol stacks, for non-limiting examples, Ethernet, VLAN, MPLS, IP, TCP, HTTP, and so on. More protocols have been added recently such as NVGRE, VxLAN and STT, and more will be added in the future. In addition, the packet header also needs to support different non-standard customer-specific protocols. As such, it is common for a packet to have eight or more different header fields during the time it travels on the network.
In order for the engines to be able to correctly process the network packets, each header of these packets is parsed by a Parser in the system. The outputs of the Parser are “tokens”, wherein one token is generated per packet and has a predefined format so the engines can understand and process the token.
The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent upon a reading of the specification and a study of the drawings.